Subject: 16/15 Character Netbios Names

From: "Steve Klein" <[email-masked]>
Date: Wed, 8 Jun 94 14:55:59 EDT

The phenomenon that we are seeing with the magic 16th byte are
qualified NETBIOS names.  The NETBIOS names that Paul Brittain describes
in his (Wed, 1 Jun 94 12:28:43 BST) note for MS LANMAN look just like the
OS/2 LAN Server/Requester names.  I asked one of the OS/2 LAN
Server/Requester developers about it and he said that for them the 16th
byte is a 'name type'.  A x'03' indicates a 'message name' (a user on the
workstation) and a x'05' indicates a 'forwarded name' (name on the
workstation being forwarded to another workstation).  For some reason
these applications look for a forwarded name before they look for a
'regular' name.

We have also seen applications that use the 16th byte as a resource type
for the workstation (printer, disk, etc.).  However, there is nothing
in the NETBIOS architecture that prevents an application from using
all 16 bytes of the destination name field as a unique name.

Paul Brittain's note shows a 6611 scenario where the 6611 handles the
x'03' NAME_QUERY differently than the x'05' NAME_QUERY.  I agree with
his proposed flow for the same situation (ie. one x'05' NETBIOS_NQ and
one x'03' NETBIOS_NQ with absorption of retries at the origin DLSw and
local retries at the target DLSw).

Here are my comments on Paul's proposal for NETBIOS:

>The detailed processing in this proposal is as follows:
>
> - When receiving a NQ from the LAN, a DLSw always treats all 16 bytes as
>   significant in the names.  This will cause it to create two control
>   blocks during a LANMAN circuit setup sequence, one each for the NQx05
>   and the NQx03.

I agree.  Leaving a 15 or 16 byte name configuration option will be too
confusing to users who have no idea what convention their NETBIOS
applications use.

>
> - Retries on a NQ on the LAN are absorbed as long as the control block
>   still exists, otherwise they are treated as a new setup attempt.

I agree.  However, you may want to say 'treated as a new SEARCH attempt'.
The new separation of topology and circuit establishment flow has the
NETBIOS_NQ and NETBIOS_NR as explorer only frames.  A CANUREACH and
ICANREACH will be used to set up the circuit.

>
> - Control blocks are timed out if they remain in the DISCONNECTED state
>   (i.e. the circuit setup fails).  The timeout period is locally
>   configurable.
>

We can leave the amount of time that a search is outstanding up to the
origin DLSw based on a configured value, available memory, or whatever
it chooses.

> - The target DLSw behaves similarly for each NETBIOS_NQ received over
>   TCP/IP.
>

I assume you mean that the target DLSw will do local retries of the
NETBIOS NAME_QUERY.

> - When it receives a NR over the LAN, the target DLSw tries to match it
>   against any outstanding NETBIOS_NQ control blocks using 16 byte name
>   significance.  If this fails, it could (optionally?) try for a 15 byte
>   match.

I think it should do the match based on all 16 bytes of name since the
NAME_RECOGNIZED could contain a session identifier for that particular
name type.

>
> - If a match is found, the target DLSw sets up whatever circuit control
>   block it needs in order to be able to send a NETBIOS_NR back to the
>   origin DLSw with the full circuit ID specified.

The NETBIOS_NQ_ex and NETBIOS_NR_ex do not establish circuits.

>
> - On receipt of a NETBIOS_NR, the origin DLSw matches the name specified
>   in exactly the same way as the target searched for a match.  If a match
>   is found, it sends the NR on the LAN, sets up a circuit control block
>   and sends an RA with the fully specified circuit ID.  If no match is
>   found, the origin DLSw returns a HALT_DL_NO_ACK to tidy up the circuit.

Again, no circuit setup should be occurring.

>
> - Circuit setup then follows the usual FSM as the SABME and UA flow.
>
> - Any NQ/NR control blocks that were set up but never resolved (e.g. the
>   NQx05 for LANMAN) are eventually timed out and discarded.

I agree.  The new NETBIOS flow has a CANUREACH_cs being generated by
the SABME (the first directed frame) to initiate a circuit.

Steve

---

From: Ravi Periasamy <[email-masked]>
Date: Wed, 8 Jun 94 17:31:00 EDT

Hi,
 
One of the problems with handling 16 or 15 bytes of the netbios names is
caching the names. The problem and the assumptions I have made in this
solution:
 
Most of the netbios environments use 15 byte names and the 16th byte is
used by the application to denote the name type or the resource type.
 
Some netbios implementations permit use of all 16 bytes in the names.

The problem with using only 15 bytes is the probability that some name
may be 16 bytes long and the difference in names between two different end
stations may be the 16th byte.

The problem with using all 16 bytes is caching of names will take up more
space as we may end up caching more than one name for the same end station.

Give the problems and assumptions, the main goal of this proposal is to 
solve the problem associated with name caching.

Proposal:

If the last byte is a printable character, it is probably a name where all 16
bytes were used. If it is a non printable character, it is probably a name
with 15 characters with the 16th byte used by the application. So all the DLSw
implementation has to do is check for this before taking a decision to store
the name in the cache.

If the last byte was used by an application which puts in a printable character
then the worst that will happen is that we will end up using an extra entry for
the same end station. But this may not happen very often as applications
tend to use numbers which are not printable (or atleast not on the keyboard).

The only problem is if the user uses the last byte, but for some strange reason
uses a non printable character in the 16th byte. I do not think that this is
probable. If anybody knows/thinks otherwise, please correct me.

Ravi Periasamy,
[email-masked]

---

From: Robin Layland <[email-masked]>
Date: Thu, 9 Jun 94 08:28 EST

I agree with Ravi proposal. Pauls and Steve proposal using the 16 bytes 
always will lead to problems with table size. I know this from experience. A 
network with 10,000 names will generate 30,000 to 50,000 unique 16 byte 
names. The table was big enough with 10,000. Plus it goes beyond the table 
size. Each new Netbios names causes the CANUREACHs to be sent to every 
location. Since it is highly likely that during the day the end-station will 
use a different value in the 16th byte while session are active we will lost 
the benefit of learning. Add to this is that I have seen few servers or 
client that let an end-user configure the name past eight characters. Check 
your testing and you will find bytes 9 to 15 are binary zeros.

Lets not get to far from relaity to handle possible situations that we have 
never seen. People are not out writing new netbios system code so what we 
see currently out their is what we will see in the future.

The proble of someone using a nonprintable character in the 16 bytes and 
using all 16 bytes is as close to zero as you can come. Plus we should not 
lost the benefit of learning because someone out their does something that 
is really odd. It is just to unlikely besides being very difficult to do.
.
Robin Layland

Ravi's Proposal:

If the last byte is a printable character, it is probably a name where all 
16
bytes were used. If it is a non printable character, it is probably a name
with 15 characters with the 16th byte used by the application. So all the 
DLSw
implementation has to do is check for this before taking a decision to store
the name in the cache.

If the last byte was used by an application which puts in a printable 
character
then the worst that will happen is that we will end up using an extra entry 
for
the same end station. But this may not happen very often as applications
tend to use numbers which are not printable (or atleast not on the 
keyboard).